A database is, fundamentally, a computerized record-keeping system in which large amounts of information may be stored in a structured manner for ease of subsequent retrieval and processing. Large databases such as the DB2® database from the International Business Machines Corporation of Armonk, N.Y., are typically managed through a database management system (“DBMS”).
At times, a database may need recovery. There are two types of recovery-logical and disaster. Logical recovery generally refers to situations in which the data is physically present on a disk, but unusable due to logic errors. Disaster recovery generally refers to situations in which a disk has been damaged such that the data is unavailable.
It is important that after recovery of a database (or a portion thereof) the recovered database is both physically and logically consistent. To ensure this consistency, prior art database recovery techniques such as point-in-time (PIT) recovery require one or more table and index spaces to be disabled for application access while the data is being recovered. While this process generates a consistent recovered database, it prevents users from reading or updating the database objects until the database is recovered. This can be a significant drawback for large or complex databases and/or those databases that experience large update volumes.
Often times, most of the pages of the spaces are outside the scope of the PIT recovery, yet the pages remain unavailable far processing. For customers with a large number of online users, and assuming that the number of users affected by the PIT recovery is small, the unnecessary outages for the unaffected users can be costly. One approach has been to disable access to only the space being recovered. Although this may reduce the time needed to recover a database, access to the spaces in a recovery process is interrupted until all pages in each space have been recovered.